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INTRODUCTION 

Compilers  today  have  become  very  good  at  optimizing  code  that  has  not  been  written  in  the 
most  efficient  manner  possible.  Many  coders  often  take  this  for  granted  and  do  not  spend  time 
concerning  themselves  with  the  performance  of  their  code  and  mistakenly  rely  on  compilers  to  detect 
and  correct  inefficiencies.  One  simple  example  of  why  coders  should  pay  attention  and  not  rely  on 
compilers  to  do  the  thinking  for  them  is  when  to  use  prefix  or  postfix  in  their  code. 

Most  coders  coming  out  of  school  today  all  know  the  basic  difference  between  these  two 
lines  of  code: 

function(++variable); 

function(variable++); 

The  basic  difference  is  that  the  first  function  call  will  be  sent  an  incremented  variable, 
whereas  the  second  one  will  receive  the  current  value  of  the  variable  and  then  the  variable  will  be 
incremented  upon  return  from  the  function.  So,  many  coders  will  be  comfortable  with  that  knowledge 
but  not  think  there  is  any  difference  between  the  next  two  lines  of  code: 

variable++; 

++variable; 

In  the  end,  both  of  these  lines  of  code  will  increment  the  variable,  but  the  concern  is  how. 


METHODOLOGY 

In  order  to  understand  the  difference  between  these  two  notations,  what  is  produced  by  the 
compiler  must  be  discussed.  Without  optimization,  the  compiler  must  create  a  copy  in  order  to 
accomplish  a  postfix  increment  or  decrement.  The  prefix  does  not  require  this  and  is,  therefore, 
more  efficient.  Most  modern  compilers  can  detect  and  optimize  the  simple  cases  like  the  cases 
involving  basic  built-in  types.  This  should  not  be  relied  upon  and  it  should  be  a  habit  to  always  use 
prefix  unless  specifically  needed  to  postfix.  Take  for  example  the  following  code: 

for(int  i  =  0;  i  <  SomeNum;  i++)  {  doAnything; } 

Most  college  professors  and  books  will  show  loops  written  in  this  way.  So,  coders  that  have 
seen  loops  mostly  written  in  this  way  will  continue  to  write  them  in  the  same  fashion.  It  is  not 
necessary  to  postfix  increment  for  this  loop.  Even  though  most  compilers  will  optimize  this  properly 
in  most  cases,  this  should  always  be  written  for  loop: 

for(int  i  =  0;  i  <  SomeNum;  ++i)  {  doAnything; } 

So  let’s  take  a  look  at  some  assembly.  Modern  compilers  will  produce  the  following  after  they 
optimize  this  code: 


//prefix  built  in  type 
;  21  :  for(auto  i  =  Ou;  i  <  10000;  ++i) 
mov  DWORD  PTR  _i$l[ebp],  0 

jmp  SHORT  $LN3@wmain 

mov  eax,  DWORD  PTR_i$l[ebp] 

add  eax,  1 

mov  DWORD  PTR  _i$l[ebp],  eax 

cmp  DWORD  PTR  _i$l[ebp],  10000;  00002710H 

jae  SHORT  $LNl@wmain 
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:22 

jmp  SHORT  $LN2@wmain 


//postfix  built  in  type 
;  21  :  for(auto  i  =  Ou;  i  <  10000;  i++) 
mov  DWORD  PTR  _i$l[ebp],  0 

jmp  SHORT  $LN3@wmain 

mov  eax,  DWORD  PTR  _i$l[ebp] 

add  eax,  1 

mov  DWORD  PTR  _i$l[ebp],  eax 

cmp  DWORD  PTR  _i$l[ebp],  10000;  00002710H 

Jae  SHORT  $LNl@wmain 

:22  :; 

Jmp  SHORT  $LN2@wmain 

As  one  can  see,  the  optimized  code  is  exactly  the  same.  The  following  loops  are  an  example 
of  code  that  is  a  little  trickier  for  the  compiler  to  optimize: 


auto&  it  =  my_ints.begin(); 
while(it  !=  myjnts.endO) 
it++; 

auto&  it  =  my_ints.begin(); 
while(it  !=  myjnts.endO) 
++it; 


The  variable  ‘it’  is  a  vector  iterator.  The  prefix  and  postfix  increment  line  of  code  produces 
the  following  assembly  code: 


//iterator  prefix 
00F755E2  mov 
00F755E5  call 
00F755EA  Jmp 


ecx,  dword  ptrjitj 

std::_Vector_iterator<std::_Vector_val<std::_Simple_types<unsigned  int>  >  >::operator++  (0F711F9h) 
wmain  +  0EEh{0F7558Eh) 


//iterator  postfix 
002E5A12  push 
002E5A14  lea 
002E5A1A  push 
002E5A1B  mov 
002E5A1E  call 
002E5A23  lea 
002E5A29  call 


0 


eax,  [ebp  -  17ChJ 
eax 

ecx,  dword  ptr[it] 

std::_Vector_iterator<std::_Vector_val<std::_Simple_types<unsigned  int>  >  >::operator++  (02E10FFh) 
ecx,  [ebp  -  17ChJ 

std::_Vector_iterator<std::_Vector_val<std::_Simple_types<unsigned  int>  > 
>::~_Vector_iterator<std::_Vector_val<std::_Simple_types<unsigned  int>  >  >(02E119Ah) 

002E5A2E  Jmp  wmain  +  OEEh  {02E59BEh) 


As  one  can  clearly  see,  the  compiler  was  unable  to  optimize  the  postfix.  It  had  to  create  the 
copy.  Figure  1  displays  how  long  it  takes  to  run  through  the  previous  code  for  a  certain  number  of 
iterations. 
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CONCLUSIONS 

The  C++  coders  need  to  take  the  time  to  understand  implications  of  the  code  that  they  create. 
Some  of  the  most  benign  looking  code  can  have  a  significant  impact  on  the  performance  of  a  piece 
of  software  that  can,  in  turn,  affect  the  device/system  that  is  running  it.  An  easily  addressable 
example  of  this  is  the  prefix  and  postfix  notation.  A  coder  should  always  use  prefix  notation  unless 
they  have  to  use  postfix. 
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